REMARKS/ARGUMENTS 



Amendments were made to the specification to correct errors and to clarify the specification. No 
new matter has been added by any of the amendments to the specification. 

Claims 1, 2, 4, 7-9, 11, 13, 14 and 16 are pending in the present application. Claims 1, 2, 4, 7-9, 
11, 13, 14 and 16 have been amended, and Claims 5, 12 and 17 have been cancelled, herewith. 
Reconsideration of the claims is respectfully requested. 

I. Objection to Specification 

The Specification was objected to due to minor informalities. Several acronyms were pointed out 
as being improperly used without proper definition when first used. Applicants have amended the 
Specification to include definitions for the following acronyms: PDA, JNDI and URL. As to the other 
listed acronyms, Applicants believe they are already properly defined in the Specification, as follows: 

API - defined at page 14, line 2 of the Specification. 

IPR - defined at page 5, line 25 of the Specification (in the Figure 5 description). 
ISMP - defined at page 14, line 1 of the Specification. 

Therefore, the objection to the Specification has been overcome. 

II. 35 U.S.C. § 101 

Claims 13-14 and 16-17 stand rejected under 35 U.S.C. § 101 as being directed towards non- 
statutory subject matter. This rejection is respectfully traversed. 

In rejecting Claims 13-14 and 16-17, the Examiner alleges "A computer readable medium 
product is a tangible physical article or object, some form of matter, which a signal is not". While 
Applicants deny such assertion, Applicants are in any event amending Claim 13 as suggested by the 
Examiner in order to place this case in condition for allowance. 

Therefore, the rejection of Claims 13-14 and 16-17 under 35 U.S.C. § 101 has been overcome. 

III. 35 U.S.C. § 102. Anticipation 

Claims 1-2, 4-9, 1 1-14 and 16-17 stand rejected under 35 U.S.C. § 102(e) as being anticipated by 
U.S. Patent No. 6,75 1 ,794 to McCaleb et al. (art made of record, hereinafter "McCaleb"). This rejection 
is respectfully traversed. 
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Generally, Claim 1 is directed to an installation process that is substantially different from the 
teachings of McCaleb, in that (1) the host/server maintains particular configuration information that was 
used when a prior version of a software module was previously installed, thereby advantageously 
facilitating subsequent, newer installs providing a higher level of automation during such subsequent 
installs by reusing some or all of the previous configuration information, without having to query the 
client for such additional information; (2) a set of instructions is sent by the server to the client to 
effectuate an instal l of the software module at a later time as designated by the set of instructions, such 
that the client can later pull the software module from the server to effectuate the subsequent install - 
thereby advantageously allowing for each individual client to pull the software module at different times 
from a common server to mitigate software upgrade bottlenecks that could otherwise occur; and (3) the 
use of a multicast address to locate a server containing software module update information to provide 
greater flexibility in overall system adaptability and reconfiguration by not requiring the use of specific, 
fixed addressing. These distinctions will now be described in detail. 

Claim 1 has been amended to expressly recite "wherein the knowledge base of prior installations 
is located in an installed product registry at the server data processing system and includes a mapping 
between user identities and prior user installation configuration data that was previously used when 
configuring a previously installed version of the software module". As can be seen, the server data 
processing system includes an installed product registry that includes prior user installation configuration 
data. In contrast, per the teachings of the cited McCaleb reference, only the client-installed applications 
themselves are known to the server, and the server must query the client for configuration information if a 
request for an update is received from the client (McCaleb col. 3, line 59 - col. 4, line 24; Figure 2, block 
210). Per the features of amended Claim 1, such configuration request is advantageously eliminated by 
the server itself maintaining such configuration information for each client. 

Claim 1 has also been amended to expressly recite "wherein the set of instructions includes a 
future time to request the software module from an installation server, and wherein the set of instructions 
is subsequently executed on each client data processing system in the set of client data processing systems 
to pull the software module from the installation server and install the software module on the set of client 
data processing systems". As can be seen, the set of instructions that are sent by the server data 
processing system include a future time to request the software module from an installation server, 
thereby eliminating the need for the server to push the application to each of the client machines. In 
contrast, per the teachings of McCaleb, both the application being updated as well as installation 
instructions are both sent to the client device in response to the request by the client device for an update 
(McCaleb col. 4, lines 39-44). In the McCaleb scenario, the server is at the mercy of the client request for 
an update, which can lead to server-related bottlenecks in large systems with lots of requesting clients. In 
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contrast, per the features of Claim 1, the server can designate when the client should pull the update, thus 
providing better workload balancing and scaling in large systems. 

Further yet, Claim 1 has been amended to expressly recite "discovering a configuration of each 
client data processing system in the set of client data processing systems by the at least one client data 
processing system sending a request to a multicast address and receiving in response a uniform resource 
locator (URL) of where the configuration is located on a server data processing system". In contrast, per 
the teachings of McCaleb the client must know ahead of time of where the update server is located, such 
that client requests can be properly sent to the server, as it is the client that initiates the overall update 
process (col. 4, lines 11-18). This claimed feature provides greater flexibility in overall system 
adaptability and reconfiguration by not requiring the use of specific, fixed addressing by instead using 
multicast addressing to locate a server - again a useful benefit in large systems requiring ease of 
adaptability when a system grows and needs to be reconfigured (such as moving/re-assigning server 
addresses) to accommodate such growth. 

It is therefore respectfully submitted that the amendment to Claim 1 has overcome the present 35 
U.S.C. § 102(e) rejection and this claim is now in condition for allowance. 

Applicants traverse the rejection of Claims 2 and 4 for reasons given above with respect to Claim 
1 (of which Claims 2 and 4 depend upon). 

Claim 5 (and similarly Claims 12 and 17) have been cancelled herewith without prejudice or 
disclaimer as the features of Claim 5 are now included in amended Claim 1 . 

Applicants traverse the rejection of Claims 6-9, 11, 13, 14 and 16 for similar reasons to those 
given above with respect to Claim 1. 

Therefore, the rejection of Claims 1-2, 4-9, 1 1-14 and 16-17 under 35 U.S.C. § 102(e) has been 
overcome. 

IV. 35 U.S.C. § 102, Anticipation 

Claims 1, 7-8 and 13 stand rejected under 35 U.S.C. § 102 as being anticipated by U.S. Patent 
No. 6,990,660 to Moshir et al. (art made of record, hereinafter "Moshir"). This rejection is respectfully 
traversed. 

The amendment to Claim 1, as described above, has similarly overcome the present rejection of 
Claim 1 as the cited Moshir reference does not teach (or suggest) the claimed feature of "creating, by the 
server data processing system, a set of instructions using a knowledge base of prior installations, wherein 
the set of instructions is tailored for each client data processing system in the set of client data processing 
systems based on the configuration for the each client data processing system in the set of client data 
processing systems, wherein the set of instructions includes a future time to request the software module 
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from an installation server, and wherein the set of instructions is subsequently executed on each client 
data processing system in the set of client data processing systems to pull the software module from the 
installation server and install the software module on the set of client data processing systems, and 
wherein the knowledge base of prior installations is located in an installed product registry at the server 
data processing system and includes a mapping between user identities and prior user installation 
configuration data that was previously used when configuring a previously installed version of the 
software module". Instead, the cited reference teaches a substantially different technique whereby an 
administrator at a server data processing system is presented with detailed reports of current patch status 
for client computers within a network, and the administrator must then manually deploy particular patches 
by selecting a date and time for such patch deployment (col. 4, lines 25-29). As to the deployment of the 
updates themselves, the updates are listed in update lists on an update server (col. 4, lines 30-34), and an 
update agent on a client scans this update list to see if a new package should be installed (col. 4, lines 39- 
48). The server does not send any type of specially tailored instructions to a client as per the features of 
Claim 1 . Thus, amended Claim 1 is not anticipated by the cited Moshir reference. 

Applicants traverse the rejection of Claims 7-8 and 13 for similar reasons to those given above 
with respect to Claim 1 . 

Therefore, the rejection of Claims 1, 7-8 and 13 under 35 U.S.C. § 102 has been overcome. 

V. Conclusion 

It is respectfully urged that the subject application is patentable over the cited references and is 
now in condition for allowance. The Examiner is invited to call the undersigned at the below-listed 
telephone number if in the opinion of the Examiner such a telephone conference would expedite or aid the 
prosecution and examination of this application. 

DATE: July 16, 2007 

Respectfully submitted, 

/Wayne P. Bailey/ 

Wayne P. Bailey 
Reg. No. 34,289 
Yee & Associates, P.C. 
P.O. Box 802333 
Dallas, TX 75380 
(972) 385-8777 
Attorney for Applicants 
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